The IP Multimedia Subsystem (IMS) is the 3rd Generation Partnership Project's (3GPP) vision for a converged telecommunications architecture that merges cellular and Internet technologies to uniformly deliver voice, video, and data on a single network. Currently one of the hottest topics in telecom, IMS is rapidly becoming the architecture of choice for operators who wish to upgrade their existing cellular and fixed-line networks.
FIG. 1 shows a simplified view of the IMS architecture, which is divided into three parts: the service layer, the control layer and the access network. IMS applications are hosted in the service layer. This layer consists of SIP (Session Initiation Protocol) application servers (AS) which execute IMS applications and services by manipulating SIP signaling and interfacing with other systems. The control layer of the IMS network consists of nodes for managing call setup, management and release. At the heart of the control layer is a specialized SIP server called the Call Session Control Function (CSCF); all SIP signaling traverses this essential node. The CSCF inspects each SIP message and determines if the signaling should visit one or more application servers. Finally, the Media Gateway Control Function (MGCF) connects with circuit switch networks. The access network consists of IP routers and PSTN switches that provide access to the IMS network both from contemporary IP telephony devices and older circuit switch devices respectively.
In current IMS architecture, for an incoming PSTN (Public Switched Telephone Network) call, if a customer wants to get the IMS subscriber's billing information, it can only get therefrom CDR (Call Detailed Record) data by using CDR parsing tools. But the customer cannot obtain real-time billing records, which therefore needs additional CDR equipment for further analysis, especially during call talking.
FIG. 2 is a flow chart of a conventional call between an IMS network and a PSTN network, in which the billing server generates billing information based on the CDR sent by the AS at the end of the call, and the billing server cannot do the real time billing. The detailed signaling process is as follows:                when a SIP user wishes to begin a session with a PSTN user, the SIP node issues an INVITE request;        upon receipt of the INVITE request, the CSCF sends this request to the MGCF, and the MGCF maps it to an IAM (Initial Address Message) message and sends this IAM to the PSTN switch;        the PSTN switch indicates that the address is sufficient to set up a call by sending back an ACM (Address Complete Message) message;        the “called party status” code in the ACM message is mapped to a SIP provisional response 18x, which is returned to the SIP node;        when the PSTN user hangs off, the PSTN switch sends an ANM (Answer Message) message to the MGCF, and the MGCF maps it to an INVITE final response (200);        the INVITE final response is sent to the SIP node, and the SIP node sends back an ACK to acknowledge receipt;        the two users begin to talking;        when the PSTN user hangs up, the PSTN switch sends a REL message to the MGCF in order to cancel the call;        the MGCF maps the REL message to a BYE message;        the BYE is sent to the SIP node, and the SIP node sends back a 200 to confirm;        the MGCF maps the 200 to a RLC (Release Complete Message) message and sends this RLC to the PSTN switch;        the AS generates a CDR and sends it to the billing server.        
A conceivable solution for getting the real time billing information is to encapsulate the ISUP (ISDN User Part) message in SIP MIME (Multipurpose Internet Mail Extensions) body. But in current IMS architecture, the application server cannot parse the SIP ISUP MIME body. Therefore, it is necessary to add different decode functions for different country variants. The AS must call different decode functions for the ISUP information in SIP MIME body with different country variants.
FIG. 3 shows the problem occurred in the above-described solution of real time billing. As shown in FIG. 3, the PSTN switch sends a charge message (CRG) indicating the billing rate of a call to the MGCF after receiving the IAM message, which CRG message is of the signaling No. 7 and includes billing information. Then, the MGCF encapsulates this CRG into the 18x message, which is a provisional response, and sends this 18x the AS. In order to obtain the billing rate, the AS must call different decode functions for the ISUP information in SIP MIME body with the different country variants. After the call having been set up, the PSTN switch sends another CRG message indicating the interval of billing of a call to the MGCF. The MGCF encapsulates this CRG message into an INFO message, which is a message carrying call related control information, and then sends the INFO message to the AS. As such, the AS must call different decode functions for the ISUP information in SIP MIME body with the different country variants for obtaining the interval of billing. In this way, the billing server could generate the real time billing information. It can be therefore seen that, the above solution is complex and costly.
For another approach, if a customer wants to get the almost real time billing information, the application server needs to transmit CDRs to the billing machine frequently, which will highly impact the application server performance.